Migrate from BotFramework to TeamsSDK by heyitsaamir · Pull Request #302 · vercel/chat

heyitsaamir · 2026-03-26T00:42:44Z

Hello! I am the maintainer for TeamsSDK, which is the official SDK for Microsoft Teams. We noticed that y'all are using BotFramework in the adapter here which is actually now deprecated. We took the initiative to migrate you guys over to TeamsSDK. Hope that's okay!

Some wins:

Port to our SDK which is now being actively maintained.
Better type safety all around - we have better type safety not only for Teams entities, but also Graph so the adapter doesn't need to maintain Graph types).
Less code for setup
Reactions support

Pending:

I need to go through all the unit tests that y'all had and make sure I'm not missing any major ones. I manually tested everything so it should be okay, but will add UTs as well.

What didn't make it:

We don't really support Certificates. We have client-secret support, User managed identity support, and Federated Identity Credentials support. But no certs. If someone really wanted it, then can pass their own token generator as part of token option (which is basically a factory that generates a token). Our general logic was that if someone is using certs, they might as well just use secrets.
I changed the AdapterOptions to be closer to what TeamsSDK App has instead of what BotFrameworked has. If we want to maintain backward compatibility, I'm happy to keep that outward facing interface and map to our App options.

Some things I would like to add in a followup (or even in this):

Simpler code - 1 giant file is hard for me and Claude to work through :) Wanted an okay from someone on the team here before I move some code to their own smaller files.
I would like to migrate the cards logic over to our cards package as well which also offers better type safety over just raw jsons.
We have modal support as well. I'd like to add support for that next.
I know the setup is inconvenient right now, so we are working on a solution improve that as well.

Summary

Test plan

Tested the scenarios in the example bot.
Eg Channels:

DMs:

(Happy to share more screenshots / video if needed).

Replace botbuilder/botframework-connector with @microsoft/teams.apps (TeamsSDK v2.0.6). Breaking changes: - Remove certificate auth (TeamsAuthCertificate) — use token or managedIdentityClientId instead - Env vars changed: TEAMS_APP_ID → CLIENT_ID, TEAMS_APP_PASSWORD → CLIENT_SECRET, TEAMS_APP_TENANT_ID → TENANT_ID - Reactions now work (addReaction/removeReaction) instead of throwing NotImplementedError - Graph API calls use @microsoft/teams.graph-endpoints typed endpoints Key changes: - BridgeHttpAdapter captures TeamsSDK route handler for serverless dispatch - Event handlers registered via app.on() (message, messageReaction, card.action, conversationUpdate, installationUpdate) - Outbound calls use app.send() and app.api.conversations.activities() - Stream support via post+edit (native HttpStream when SDK exports it) - Graph API uses typed endpoints from @microsoft/teams.graph-endpoints - isMention detection via activity entities instead of bot name matching Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

- Replace custom config fields with Pick<AppOptions, ...> clientId (was appId), clientSecret (was appPassword), tenantId (was appTenantId) - Remove TeamsAuthFederated, appType — use managedIdentityClientId directly - Constructor passes config through to App (App handles env var resolution) - Use this.app.id instead of this.config.appId for bot identity checks - 3 replay-fetch-messages tests have known failures (type shape mismatch) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

- Remove useless private api() getter, use this.app.api directly - Type handlers with specific activity types: handleMessageActivity(ctx: IActivityContext<IMessageActivity>) handleAdaptiveCardAction(ctx: IActivityContext<IAdaptiveCardActionInvokeActivity>) handleReactionFromContext(ctx: IActivityContext<IMessageReactionActivity>) - Remove unnecessary casts now that ctx.activity is properly typed Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Keep Azure OpenAI and DM handler changes as local-only, not part of the migration. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Keep only adapters.ts config changes, revert package.json dep changes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

vercel · 2026-03-26T00:42:49Z

@heyitsaamir is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

- New env vars: CLIENT_ID, CLIENT_SECRET, TENANT_ID - New config: clientId, clientSecret, tenantId, token, managedIdentityClientId - Remove certificate auth docs (dropped) - Reactions now supported (add/remove) - Typing indicator now supported - Graph API uses @microsoft/teams.graph-endpoints - Note streaming and modals status Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

This reverts commit 729fe46.

bensabic · 2026-03-26T11:56:27Z

Hey @heyitsaamir!

Thank you so much for this.

Quick comment: would you be able to also add support for Task Modules?

heyitsaamir · 2026-03-26T13:41:02Z

Hey @heyitsaamir!

Thank you so much for this.

Quick comment: would you be able to also add support for Task Modules?

Yes! Would you like me to add that in this same pr or follow up? My plan was on a follow up.

Split the 2,114-line index.ts into focused modules: - types.ts: TeamsAdapterConfig, TeamsThreadId, TeamsChannelContext - errors.ts: handleTeamsError as standalone pure function - graph-api.ts: TeamsGraphReader class with all Graph API read methods index.ts shrinks to ~1,133 lines, delegating graph reads to TeamsGraphReader which receives dependencies via constructor injection. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

heyitsaamir · 2026-03-26T21:52:47Z

@bensabic Created this Issue when it comes to modals on Teams - #306. Lmk what you think!

bensabic · 2026-03-26T22:28:05Z

@heyitsaamir I wasn't sure what they meant either, looked like spam or a bot—just deleted the comments to reduce noise.

Thank you for the very detailed issue, I just replied to it for the sake of the PR thread being cleaner. It makes sense why modals support would need to be in a separate PR, since the underlying mechanics itself for how we handle modals would have to be tweaked slightly.

Unrelated: does the Teams SDK have support for slash commands? That would be amazing if so. As the dream is for all adapters to be as close together as possible in terms of functionality.

heyitsaamir · 2026-03-27T00:00:37Z

@heyitsaamir I wasn't sure what they meant either, looked like spam or a bot—just deleted the comments to reduce noise.

Thank you for the very detailed issue, I just replied to it for the sake of the PR thread being cleaner. It makes sense why modals support would need to be in a separate PR, since the underlying mechanics itself for how we handle modals would have to be tweaked slightly.

Unrelated: does the Teams SDK have support for slash commands? That would be amazing if so. As the dream is for all adapters to be as close together as possible in terms of functionality.

Sweet. I'm happy to put up a PR stacked on this, or once this goes in (if y'all are okay with it).

As for slash commands - we currently have a version of it:
https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/create-a-bot-commands-menu?tabs=desktop%2Cjavascript
Here, it will suggest some slash commands for the user, and you declare them in your manifest. But triggering them essentially just dumps the command in your compose box. And the user needs to send them. So it acts like a regular, pre-built, message.
There's actually something called "suggested actions" which is basically this, but dyanamic (i.e. you can pass it alongside your message). The user can click on these suggestions and it'll do the same -- put it in the compose box that the user then needs to send.

The biggest downside with the current method is that in a group-chat, everyone sees the slash-message. In a DM it doesn't really matter that much.

I will say that there are some more things coming soon that will enable better slash-command like experience soon.

heyitsaamir · 2026-03-27T00:12:56Z

btw @bensabic I refactored a bit to split the giant index.ts into two files. Hope that's okay. The first file was just getting wildly unwieldy.

bensabic

@heyitsaamir finally had a chance to formally review it.

The Teams SDK migration is directionally good, but this PR currently introduces a few blocking regressions and leaves the repo in a failing state.

The public adapter contract changes in a breaking way without a compatibility layer. @chat-adapter/teams is still on the 4.x line, but the exported config now switches from appId / appPassword / appTenantId / TEAMS_APP_* to clientId / clientSecret / tenantId / CLIENT_*. Existing consumers will break on upgrade, and the examples/docs are still inconsistent about which env vars actually work.
The PR currently breaks local typecheck/test surfaces. packages/integration-tests fails typecheck because the replay helper still expects appId while several updated callers now pass clientId, and the Teams-heavy replay/integration subset is also failing on this branch. That needs to be fixed before we can trust the migration coverage.
Channel-thread history regresses for ordinary Teams channel traffic. The new channel-context caching only persists state when channelData.team.aadGroupId is already present, but the recorded payloads in this repo only carry team.id. Without the old fallback/recovery path, thread-aware Graph reads fall back to the generic chat path instead of the proper channel-thread endpoints.
WebhookOptions are now stored on shared adapter state during handleWebhook(). Since the adapter instance is reused across requests, overlapping webhooks can overwrite each other’s waitUntil before the async handlers consume it. That is a real concurrency bug for production webhook handling.
Outgoing reaction support is incomplete. Incoming Teams reactions are normalized into Chat emoji names like thumbs_up, but outgoing reactions are sent back to Teams using emoji.name directly. That means common flows like echoing a received reaction back will send thumbs_up instead of the Teams token like.
Env-only tenant autodetection does not fully reach proactive paths. openDM() and channel-info logic still read this.config.tenantId, but values resolved internally by the Teams SDK app are not copied back into adapter config. In practice, env-only setups can still fail until an inbound event has already cached tenant state.

bensabic · 2026-03-27T01:30:26Z

Sweet. I'm happy to put up a PR stacked on this, or once this goes in (if y'all are okay with it).

As for slash commands - we currently have a version of it: https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/create-a-bot-commands-menu?tabs=desktop%2Cjavascript Here, it will suggest some slash commands for the user, and you declare them in your manifest. But triggering them essentially just dumps the command in your compose box. And the user needs to send them. So it acts like a regular, pre-built, message. There's actually something called "suggested actions" which is basically this, but dyanamic (i.e. you can pass it alongside your message). The user can click on these suggestions and it'll do the same -- put it in the compose box that the user then needs to send.

The biggest downside with the current method is that in a group-chat, everyone sees the slash-message. In a DM it doesn't really matter that much.

I will say that there are some more things coming soon that will enable better slash-command like experience soon.

Re: Modals, I'd say wait until this PR goes in, then we can cross that bridge when we come to it.

Re: Slash commands, I'd ideally rather wait to add support for that until the Teams SDK has slash commands which are closer to Slack functionality. Mainly so the UX is more familiar to users and consistent across platforms.

heyitsaamir · 2026-03-27T01:32:42Z

Ah thanks for the closer look! Yeah I called out the breaking options in the description, so I'm happy to build a translation layer between the two.

Let me go through these suggestions, and get back to you :). Thanks Ben.

heyitsaamir and others added 6 commits March 25, 2026 16:29

Revert bot.tsx example changes from migration branch

c82dd3e

Keep Azure OpenAI and DM handler changes as local-only, not part of the migration. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Revert example package.json from migration branch

8462944

Keep only adapters.ts config changes, revert package.json dep changes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Remove unrelated skill files from migration branch

983c25c

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

heyitsaamir changed the title ~~Aamir/teams sdk migration~~ Migrate from BotFramework to TeamsSDK Mar 26, 2026

heyitsaamir and others added 4 commits March 25, 2026 18:17

Fix

3148cb7

Revert "Update README for TeamsSDK migration"

d0ee378

This reverts commit 729fe46.

update readme

55f4a94

bensabic requested a review from cramforce March 26, 2026 09:44

reliccare mentioned this pull request Mar 26, 2026

Feature request : Teams SDK #129

Open

1 task

vercel deleted a comment from AntonVishal Mar 26, 2026

vercel deleted a comment from heyitsaamir Mar 26, 2026

Clean up tests

b6507fe

bensabic requested changes Mar 27, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migrate from BotFramework to TeamsSDK#302

Migrate from BotFramework to TeamsSDK#302
heyitsaamir wants to merge 12 commits intovercel:mainfrom
heyitsaamir:aamir/teams-sdk-migration

heyitsaamir commented Mar 26, 2026 •

edited

Loading

Uh oh!

vercel bot commented Mar 26, 2026

Uh oh!

bensabic commented Mar 26, 2026

Uh oh!

heyitsaamir commented Mar 26, 2026

Uh oh!

heyitsaamir commented Mar 26, 2026

Uh oh!

bensabic commented Mar 26, 2026

Uh oh!

heyitsaamir commented Mar 27, 2026

Uh oh!

heyitsaamir commented Mar 27, 2026

Uh oh!

bensabic left a comment

Uh oh!

bensabic commented Mar 27, 2026

Uh oh!

heyitsaamir commented Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

heyitsaamir commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

vercel bot commented Mar 26, 2026

Uh oh!

bensabic commented Mar 26, 2026

Uh oh!

heyitsaamir commented Mar 26, 2026

Uh oh!

heyitsaamir commented Mar 26, 2026

Uh oh!

bensabic commented Mar 26, 2026

Uh oh!

heyitsaamir commented Mar 27, 2026

Uh oh!

heyitsaamir commented Mar 27, 2026

Uh oh!

bensabic left a comment

Choose a reason for hiding this comment

Uh oh!

bensabic commented Mar 27, 2026

Uh oh!

heyitsaamir commented Mar 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

heyitsaamir commented Mar 26, 2026 •

edited

Loading